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(57) ABSTRACT 

A system architecture enables remote browsing and admin- 
istration of physical file directories resident on a server from 
a remote client browser. The a rchitecture has a browsenarid 
a user interface TUP resident at a client. From the UI, the 
remote admi nistrator can specify a path of a physical file 
directory in a file system located at the server. The browser 
sends an HTTP request that includes the path to the server. 
A server-side script receives the client request and invokes 
a file system object to enumerate the files and/or folders for 
the directory path specified in the client request. The server- 
side script then creates a client-side script, which when 
executed at the client will instantiate a custom client-side 
object to cache the directory data and to present that data in 
a dialog UL The server returns the client-side script and 
directory data to the client, wherein the script is subse- 
quently executed to instantiate a local object to cache the 
directory data. Using the client UI, the remote administrator 
can view the directory data, navigate the data, set properties 
for the listed files or folders, add or rearrange directories, 
delete or move files, or perform other general administration 
tasks. 

23 Claims, 5 Drawing Sheets 
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SERVER ADMINISTRATION TOOL USING 
REMOTE FILE BROWSER 

TECHNICAL FIELD 
This invention relates to servers for computer network 5 
systems and to server administration tools. More 
particularly, this invention relates to remote administration 
of server file systems using remote HTTP-based browsers as 
the administration access portal for browsing and configur- 
ing directories in the file systems. 

10 

BACKGROUND OF THE INVENTION 

Acomputer network system has one or more host network 
servers connected to serve data to one or more client 
computers over a network. Clients send requests for data 
and/or services to the servers over the network. The servers 15 
process the requests and return responses to the clients back 
over the network. 

In the Internet setting, the clients typically execute a 
browser program that submits requests using conventional 
HTTP (Hypertext Transfer Protocol) request commands. 20 
Each Internet server runs a Web server software program 
that accepts HTTP requests and returns data in the form of 
Web pages or documents. The Web pages are commonly 
written in HTML (hypertext markup language) or XML 
(extensible markup language) and may include text, images, 25 
sound, video, active code, and so forth. The server transmits 
the Web pages back to the requesting client using standard 
HTTP response commands. The client browser renders the 
Web page into human-perceptible forms. 

The Web pages and other program files, such as Active 30 
Server Pages (ASP) applications or custom programs, are 
stored and organized at the server in directories. Each Web 
site consists of one or more directories that contain the 
content files (typically the home page, images, etc) and 
programs. In general, a site administrator can define two 35 
different types of directories: physical directories and virtual 
directories. A physical directory is subdirectory of the Web 
site's specified, or home, directory. A virtual directory is any 
directory not contained within the home directory. Virtual 
directories are typically used to specify different URLs 40 
(Uniform Resource Locators) for different parts of the Web 
site. 

Site administrators have traditionally used local server- 
based administrative tools to browse and configure the files 
and directories. The administrators are typically present at 45 
the server and can easily browse and configure the directo- 
ries using a familiar user interface. Many administrative 
tools that are available today also support remote adminis- 
tration that allows an administrator to browse and lo con- 
figure directories on the server from a remote computer on 50 
the network, rather than from the server itself. 

Web site administrators would like to be able to configure 
the site directories from a remote client over the Internet. 
However, remote administration over the Internet raises a 
host of problems. One problem concerns the inability to 55 
browser the server's physical files and directories from a 
remote computer over the Internet. There is no reliable 
means of determining what physical files and directories are 
located on the Web server. A remote administrator can enter 
a virtual path name, such as a URL like 60 
"www.microsoft.com\applications", but the administrator 
has no ability to browse the physical directories on the Web 
server file system, such as documents listed in the physical 
directory "C:\". To view specific physical directories and set 
valid configuration parameters, a remote administrator must 65 
know the entire path and exact name of the file on the server 
in advance. 
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Another problem that compounds the difficulty of remote 
administration of the Internet is that many Web sites imple- 
ment firewall protection that blocks many types of inquiries 
from reaching the Web server. Typically, firewall software 
only permits HTTP requests to pass through to the Web 
server, while blocking other requests. In addition, the proxy 
server also prevents machines from inside the firewall from 
directly communicating with, or seeing, the client browser, 
thus making authentication very difficult. While conven- 
tional administrative tools support remote administration 
over local networks, they do not solve the problem of 
browsing directories over an HTTP firewall/proxy server. 

Another concern is security. Allowing access to a Web 
site's files and configuration parameters may be dangerous 
in the absence of high security and authentication proce- 
dures. 

Accordingly, there remains a need for a remote adminis- 
tration tool that enables remote management of a server's 
file directory over the Internet, through a firewall, and in a 
secure manner. 

SUMMARY OF THE INVENTION 

This invention concerns a system architecture that enables 
remote browsing and administration of physical file direc- 
tories resident on a server from a remote client browser. The 
system architecture employs standard network protocol, 
such as HTTP, to enable implementation on the Internet. 

Th e architecture has a b rowser and a user interface (JJ D 
pr esented at a client. I'he Ul might be stored locally _a_U he 
client, or download^ "n riprn an rl rrnmjhe server The client^ 
UI presents files, folders, and/or direc tory trees that ar e 
c ached locally at the client to a reni ot e^admin ist rator. Th e 
ad ministrator can navigate the file s and/or tolders""of the 
c urrently cached directory path using file brow sing tools. 
The remoteTdministrator can also s ele ct a file oTfolder, o r 
s pecify a new path of a physical file directory located at the 
s erver. 

When the ad ministrator d esignates a new_path_thatisjio t 
c ached at the client, the browser sends a client requesttha t 
in cludes ttie new path to the server. The re quest conforms 
i^tr j^tanfiarH HTTP Tn tfrj s manner , me fiie_ browsing 

r equest i s protP.rtr.H within_* m .aiilhAnliValp T ] cnmrrpiryV^jnn 

path fi.e^ one that h as a1r"a H y ^fh*^T^ H ) and K^nnt^j 
passage through any firewall that may exist between the 
client and server,. 

The server receives the client requesLand invokes -aJile^ 
s ystem object used to_interface the file system. Thgjil e 
s ystem object enumerates the files and/or folders for the 
dir ectory path specified in the client request. 

Th e serv er then crea tes executable code th at will be run at 
th e cIientTo cache ana present the directory data obtained_b v 
th e file system object. In one implementation, a server-side 
sc ript creates a client-side script, which i nst antiates a c ustom 
cf ient-side object to cache t he, returned ^rec tory data and t o 
pr gsent that da ta in a dialog UI. Absent this process, the 
cl ient-side prowsu wuuld tlol know what n jps, r^if^IrT, 
a q3/or directories it will cache in order to present them in 
re sponse to the specilied path query. I he server mus pr e- 
p ares a client-Sid e, .script that will be~ahle tn cache the 
info rmation for the client and downloads that script to the 
cl ient for execution, 

The server returns the client-side executable and the 
directory data to the client. The client subsequently executes 
the script to instantiate a local object for caching the 
directory data. The data is presented in the UI, which enables 
the administrator to navigate the data, set properties for the 
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listed files or folders, create or rearrange directories, delete 
or move files, or perform other general administration tasks. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The same reference numbers are used throughout the 5 
figures to reference like components and features. 

FIG. 1 is a diagrammatic illustration of a client-server 
system showing remote administration of a server file direc- 
tory over a public network, such as the Internet. 

FIG. 2 shows a block diagram of a computer that can be 
used to implement the client and/or the server in the client- 
server system. 

FIG. 3 shows a remote file administration software archi- 
tecture according to an aspect of this invention. is 

FIG. 4 shows steps in a method for remotely browsing a 
server-based file system from a client browser according to 
another aspect of this invention. 

FIG. 5 shows a browser dialog user interface presented on 
a client computer to browse and remotely administer the 20 
server-based file system. 

DETAILED DESCRIPTION 

This invention generally pertains to a system architecture 25 
that enables remote administration of a server-based file 
directory from a remote client browser using a standard 
network protocol, such as HTTP. The system architecture is 
particularly useful for remote administration over the Inter- 
net and through one or more firewalls. Additionally, the 3Q 
system architecture enables the administration tasks to be 
performed securely over an otherwise public network. 

For discussion purposes, this invention is described in the 
context of a Web server application tailored for serving 
documents and programs over the World Wide Web. Remote 35 
administration of the Web server involves configuring and 
organizing Web pages into a hierarchy of file directories. As 
one example, the Internet Information Server (IIS) manu- 
factured and marketed by Microsoft Corporation is a Web 
server that is extremely configurable and can serve thou- 
sands of files. One aspect of this invention concerns the 
ability to browser the directories of the Web server, such as 
IIS, from a client browser. 



General Architecture 



45 



FIG. 1 shows a simple clie n t-server computer network 
system 20*with a host network server 22 c onnected to serve 
data to a client 24 via a p ublic network 26. In typical 
operation, the client 24 sends ~a~Tei ^reg t- -for- ^ata- - a ud / O t ' 
se rvices to the ser ver 12 over .the publicnetwork 26 I tie so 
s erver 22 prOcesseslhe re jauesUaadje rurns a response over 
th e public network 26. I f the request is for data, the server 
22 ~accessesji_database 2815" retr ieve the requested data 30 
ari d returns_ the L Hata_Mi as _p_a fl L nfTftg*i es-p^inse."" ' ~ 

Thej^nt^jafftK^yxtftm 2Q_is-iepiesen tatiye of many 55 
d ifferent environments. One particular environment of inter_- 
est is the I nternet. The, server 11 nig s a Web server softwar e 
p rogram thaj jsjajnishes-a-^r&b-s^ Wide yjeh 

The server 22 has a file system that organizes files, such as 
Web pag es and other documents 3 0, into hierarchical direc- 60 
toriesTT fie Weks ejyj&r_a ccepts requests transmitted overtrie ~ 
Inter net from a client-based brow ser program. The serv er 
pr ocesses the requests andreturns.one or more Web pages to 
the client 2 4 The. Wf>h p a p, pfi a re commonly written i n 
HTMLihvpfMlf.yl m arkup language) and XML (extensible 65 
m arkup language) and are tran smitted using conventional 
network protocols, such as TCP/IP (Transmission Control 



P rotocol/Internet Protocol), HTTP (Hypertext Transfer 
Pr otocol) "and L)(j6M (Distributed Component Obje ct 
Mixfel). The client browser renders the Web page into 
human-perceptible forms . 

T he server computer 22 may implement a firewall so ft- 
ware" program^, tn protect thfi Wph site Ttuvfirewall V is 
ex ecTflecfon the server computer or a dedicated compu ter, 
but is shown separately for illustration purposes. The fire- 
wall 32 blocks many types of unwanted inq uiries frnrn 
arrivin g at the Web server. Th e firewall 32 is conventional i n 
that i t permits passage ot messages contorming to standa rd 
pr6tb cols T such as , H'lTP , t h nt nrriv fl a t wpll -known an d 
such as port 80. 



designated ports, such as port 80. It is noted that other 
firewHt gmav pe imple mented in the commu mcauorTpa th 
betwee n the client and the server, such as a firewall im ple- 
mented on tne client side of the Internet 26. 

The server 22 may be connected to an internal computer 
networirbehind th e hrewall $i. in the Hti. 1 illustration , the 
ser ver"22 IS connected to a second serve r 34 via a private 
net work 3 ft <e . p r. r I AN r WANV The second server 3'4Tia s its 
own database 38 with files 40 stored therein. The server 34 
has a file system that organizes the fi les 40 into hierarchical 

direct ories. ' ■ — 

According to an aspect of this invention, a computer 
network system 20 implements a remote file administration 
architecture that enables the client 24 to browse and manage 
the server-based file directories remotely over the Internet 
26 and through the firewall 32. The architecture has software 
components residing at both the client and server and these 
components empower the client to perform such adminis- 
trative tasks as browsing and listing the file directories, 
configuring the directories, moving existing files, creating 
new files, and so on. The administration architecture utilizes 
standard HTTP commands to gain passage through the 
firewall 32. In addition, the architecture can be extended to 
allow the client to browse the directories 40 of another 
server 34 via the proxy server 22. 

The architecture and processes implemented by the archi- 
tecture are described below in more detail, following a brief 
discussion of an exemplary computing system used to 
implement the client and/or server computers. 

Exemplary Computing System 

FIG. 2 shows an exemplary computing sys tem for imp le- 
menting aspects of t he jnventinn. The computing system is 
shown embodied as a general purpose computing de vice in 
the fo rm of a conventional personal computer ^0 . The 
computer jO includes a proces s 1 ' 1 "^ unit 52, a sys tem memo ry 
54, anoHTsvste m bus 56 that inter connects various sygtpm 
compongntSTincludin g the system memory 54, to the pro- 
cessing unit 5 2rThe sy stem hus 56 may bo implemented n*; 
any one-of"several bus st ructures and using any of a vari ety 
of bus architect ures, including a m emory bus or memory 
controller, a perip heral bus, and a local bu s: — 

The system memory 54 includes read onl y memory 
(ROM) ~58~and random access memory (RA M) 60. Airasic 
input/o utout system 62 (T^OS) is s tored m KnTCmns . 

TK e computer 5 ft m n v n hn havr n n n nr morr n f t hr 
following drives: a hard disk drive 64 for reading from and 

Writin g~t6 a hard disk or harn ; msir array; a magnelir Hisk. 

drive 66 for reading from or writing to a removable magnetic 
disk 68r-a ml <ni uptlcal disk drive 7 0 f of reading fro m or 
writing' to a removable optical disk 72 such as a Cb kOM 
or other opti cal media. The hard disk drive 64. magnetic d isk 
drive 66 rana optical disk drive 70 are connected to the 
system bus 56 by a hard disk drive interface 74, a magnetic 
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disk drive interface. 7fi, and a n optical rfr lYP jptgrffl/'p 78, 
respectively. The drives and their associ ated computer- 
readab le media provide nonvolatile storage ot comput er 
readable instructions, data structures, program modules and 
ot he r data fo r the com^uTcr " 50. Although a liaiJ disk, a s 
removable magn etic disk 68, and a removabl e optical disk 
62 die Uescnbeo, other types of computer readable riiedla 
capiat um xI to Mui H.iijfm OiI^i mi-ii m , jm ] y] ^ r rmmirtir 
cassettesTfTash memory cards, digital video disks, Bernoulli 
cartridges, ran dom access memories (RAMs), re ad only 10 
memories~(R0M), and the like. 

A number of program modules may' be stored on the hard 
disk, magnetic disk 68, optical disk 72, ROM 58, or RAM 
60. These programs include an operating system 80, one or 
more application programs 82, other program modules 84, 35 
and program data 86. The operating system 80 is preferably 
a Windows brand operating system from Microsoft 
Corporation, such as Windows 98 or Windows NT, although 
other types of operating systems may be used, such as 
Macintosh and UNIX operating systems. 

An operator may enter commands and information into 
the computer 50 through one or more input devices, such as 
a keyboard 88 and a mouse 90. Other input devices (not 
shown) may include a microphone, joystick, game pad, 
satellite dish, scanner, or the like. These and other input 
devices are connected to the processing unit 52 through a 
serial port interface 92 that is coupled to the system bus 56, 
but may alternatively be connected by other interfaces, such 
as a parallel port, game port, or a universal serial bus (USB). 
A monitor 94 or other type of display device is also 
connected to the system bus 56 via an interface, such as a 
video adapter 96. 

T he computer 50 ^ope rates in a networked environme nt 
usin^lo pTcaT connections to one or more remote compute rs. 
TEe^ computer 5(L has- a network interface or adapter 98. a 
mdHem 100. or other means for establish ing co mmunica - 
tio ns over a network, such as the tnternet ZtToTTHe privat e 
LAN 3 6. It will be appreciated that the network connections 
shown ar e exemplary and other means of establishing a An 
communications ink between the computers may be used. 
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Remot e^File Admin ^tratinn Architecture 

FIG. 3 s hows a remote file administr at j^n arfrhitfrf* tllga - un 
implementJSin the clien t-server system 20 of FIG. 1 . The 
ar cbrtectuii llQuaehntes software components resident at 
the server 22 and softwar e components resident at the client 
24. Ihe softwa re components can be incorporated i nto" 
res pectiyertTperating systems 80, or implemented as^eqaxate^ 
program modules 84, at the server and 
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O n the servex ^adc . Lhe lemoto file a dministr a t i on ar chi- 
te cture 1 10 includes a file system }\ 2 and a file system 
obje ct 114 that is invoked to discover the fil e system 112 . 
Th e' server-side components further incl ude the Interne t 55 
Inf ormation Server 116 and a script 118 implemented using 
ac tive server page (ASP) technol ogy, t he script is usedlo 
p arse in coming requests to brows e or^pnflgure~the~~file 
directories and to create a cheni-siae script that iiTclown- 
loafle fl bacK to tne ctfeTit-m-respo flse-to the reqiipsts^lt is 60 
noted, no wever, that the server may alUMUat ivily implement 
code ^fofms other than scripts (e.g ., compiled ludefr-to 
implen gnt the functionality descnoeo ne i dlu with respecHe - 

T3 n the c li ent side, the remote file administration arch i- 65 
l ecture 110 includes a browser! 20 and a browser dia log 
122. In one implementation, the browser dialog 122 is built 



usi ng; a combination of server-side ASP files written using 
VBS cript and client side scripts written in JavaScript. In one 
implemen tation, the AiSP riles include: 

1. jsbrwls: A file to display a list of files or folders in a 
requested path; 

2. jsbrwflt: A file to display the currently selected file 
name, as well as the ok and cancel buttons; 

3. jsbrwcl: A file to implement the close function of the 
dialog; 

4. jsbrwpop: A file that implements the open function of 
the dialog; 

5. jsbrowser.asp: A file to display the dialog frames 
(layout); 

6. jsbrower.js: A file containing the client-side utility 
functions, such as selecting a file, and sorting the lists; 

7. jsbrwset.asp: A file that creates the cached list of folders 
and files in a requested path; and 

8. jsbrwhd.asp: A file that displays the currently selected 
path as well as the column headers. 

9. 

The remo te file adm inistration architecture is incorpo- 
rated Into exis ting hlTi J browsing t ools, ratner tnanpein g 
e mbooiea as a sell-contained* binary execu table. Incorporat- 
ing the lunctionality into the existing browser allows use of 
hi gh-level Internet authentication schemes to ensure secure 
access to the Web server 's files! ~~~~ 

Remote File Browsing 

Prior to gaining access to the server file system, the cli ent 
fi rst establishes a secure connection with the serverTThis 
in volves an authentication process in which the client a nd 
server verify each other's identities and software comp o- 
nents (if de sired) followed by encrypted communicati on 
ov er tne internet. When the client first attempts to co nnect, 
the server oners one or more authentication proceduresTVor 
Windows NT conn ections, the server oners tnree choices : 
b asic authentication, M 1LM (NT LA M Manager), a nd cer - 
ti ficates. The client elects one or tne three cnoices depen ding 
uponwhich its networking system can support. 

Assum ing the c lient elects the certificates option, th e 
cl ient and server exchange ce rtificates. These certificates 
ty pically contain an identity, a public and a digit al 
sig nature ol a IruslOJ cmltylng authority. If the certifica tes 
are verified, the client and server use the other's public keys 
to encrypt and decrypt messaged exchanged between tfi ejn. 

T he remote file adminj sjr afinn architect ure opera tes 
wi thin the context of this secured environment. Accordin g! y, 
th ^-ftmmamfo dc*™^ ^ ] " w f r ir passing path names to 
th e server and returning client scripts and data objects to the 
clie nt are all securely exchanged over the Internet and 
thro ugh the firewall. "~ 

FIG. 4 show steps in a method for remotely browsing and 
administering file directories in the server-side file system 
112 from the client browser 120. The steps are described in 
conjunction with the system of FIG. 1 and the software 
architecture of FIG. 3. The steps arc performed by various 
software components at the client and server, as designated 
by the corresponding captions in FIG. 4. 

At step 200 in FIG. 4, the client calls the browser dialog 
122 by including the script library and initializing a browser 
object, as follows: 

<SCRIPT SRC~"Browscr/JSBrowser.js"> 

</SCRIPT> 

<SCRIPT> 
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JSBrowser«new BrowserObj(null,! POP,TFILE, 

LARGEFONT); 
</SCRIPT> 

At step 202 in FIG. 4, the client opens the browser dialog 
by instantiating a new instance of the browser object with a 
predefined boolean constant POP, as follows: 

<INPUT TYPE-TEXT NAME«"pathcntrl"> 

<INPUT TYPE-BUTTON OnClick="JSBrowser=new 
BrowserObj(pathcntrl, POP,TFILE,LARGEFONT);"> 

The variable "pathcntrl" refers to a text field within an 
HTML form that will be populated by the results of the 
browser. "POP" is a constant to indicate whether the dialog 
should be launched. "TFILE" is a constant to indicate if the 
user is selecting a file or a directory. "LARGEFONT" is a 
constant that affects the dialog size. 

At step 304, tne cli ent laiinc h gs the browser 120. Fo r the 
initial launch, the browser dialog 122 displays t he last 
directory patn viewed at the client computer (step 20 6 in 
FlG<-4)TTrj e last path is retrieved from a cookie stored the 

last time the administrator launched the browser: — , , 

FIG.^ sliows t he biuwsei dn rtog422-as it is rendered on 20 be ^Tectedjyithout requiring .another roUr£-rrro-to the 
the client com puter monitor. The brow ser dialog 12 2 server. 

resembles the familiar hie management- Ul supporteefby It is noted that thr hrrnvs i nn nrnrrss can be extended to 
Winrlnwri-hranrt grating systP.mfi, if ^ r \ v ^ a *<T nnV ; T » enabTr7im o . tr fi ln hmwaiutL of u lHu ic al directories o n 
tftYt'hnY^n, a flip «nH a "File name: " text box 254. annfBercnmpiiter .mnnecfqd to t he server 22. That IS, the 

When fir st opened, the dialog 122 displays the last directory 25 server 22 operate s ?g a pmvy epry nr | Q racilitate hi UwMhp of 
path, w hrcn in this case is "C: in the "Look mX J&xt Pox nther enmpnf ers behind the , firewall a nd connected via a 
250/ Within the dialog 122. the administ rator may nai^tp. local net work. In this implementatio n, ine"nig"system-Qhiect 
up oTdownt he direc tQrx.staictur&-bv eithp. r e n tering- a path - is involg e^To enumerate trie tiles 6T tftreeteties^for the 
o4h&' 4V Xjoa\[\x^^ the requested path that resides on a separate computer, such as 



script creates a client-side script, which instantiates a custom 
client-side object to cache the returned file data such as the 
file name, last date modified, file size, and so forth. That is, 
the server generates the program that enables creation of an 
object on the client side to handle the response to the file 
directory query. Absent this step, the client-side browser 
does not know what files, folders, o r directories it will cach e. 
The server thus prepares a client-side script tSaf will be able 
to cache the information for the client and downloads that 
script to the client for execution. An example of a server-side 
script creating a client-side HTML output for execution on 
the client is given below under the heading "Client-side 
Script Generation". 

A t step 228, the server sends an HTTP response contain- 
ing tEe client-side script created a I the seivu. Thi oliout 
sra^ptigToaded and evpnitpfj fr y the cEeTTnO CllllWmte" th e 
caefa cwith the results of the director y query (step itie 

hrnwser dj alng can then display the, hsf Tifn^ yfllfc S u b t tt ffle d 

fror fi the server and cached locally (step 20 6). t5ecause~me 
daFa is cached on the client, it may be sorted of Items may 



>-«re ~Look in: MexLl 
\1gfZS2. The dialog ] 



dialogjl22.can-also display-direetofy view 30 server 34~FheTwo local computers' cuuld ube-* pngyeup'rinal 



lirectory4rec-instead-of T or-in~addition 



file 
that 

to, thej£Lo£-flies, 

With reference again to FIG. 4, i f the user selects an item 
in the-tisr232 (i.e., th e "yes" "Bran cB from step 2081 . the 
br<5wser 1^0 determines whether the contents are cached 
localiy-on the client (step 210). If th ey ire, the hrnw ser 120 
refresh es the nam (steu 212 ). Ihe n e w page indic a te s t ha t 



therrtrrfrts~Se1ecteg in some manner, su dl as ^hanpin^ th^- 
colo Tofthe selected item o r displaying 3 g ra y har-VgmiinH j 
antfsHow s the path of the se lectedLile m in the "File name : " 
text box : 254 at the botto m of the dialog. If the selected item 
is a folder, lis" contents will be enumerated and displayed in 
the lisr 252 and theJlLuuluti Atwrt4»x 250 will be updated 



?r-hi>cjnrp, svh as SMB shares or NFX shared ttrsupport 
remote object transactions. " 

The acchitectuTe"'and process enable a remote administra- 
tor to browse the physical directories on the server site. In 
35 one implementation, the architecture enables an administra- 
tor to browse and view both physical and virtual directories 
in a single integrated namespace that reflects the hierarchical 
arrangement of the site as perceived by the client. The 
remote administration tool includes a dynamic namespace 
40 integration mechanism that looks up information maintained 
in a registry (e.g., metabase) for the physical and virtual 
directories and maps the virtual directories to their appro- 
priate actual locations as necessary. The administrator then 
has a view of the site that corresponds to the view of the 
client browsing the site, i.e., in a hierarchy of the physical 
directories and the virtual directories mirroring the hierarchy 
of the URLs. The administrator may then manage the files 
under the directories in the namespace via the same entity, 
such as by setting property values via a user interface of a 
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withthe new path. 

When the ad ministrator finally selects an item or enter s a 
path thafjsnoj_cacheo^locally^^ 

passeTlTtext stri ng of the path back to^th e.Jnstantiating 
forfrrVp'atr rtexrbo x 

The Trat rT~is then passed_as^ a query— slring-Jkria-an^H j I P 

request to the server (step 214 in FIG. 4), Because the path 50 management tool. Moreover, the hierarchical relationships 

is carried4n3n3lrai4-re^ UuuugtHhe firewall between the physical and virtual directories enable the 

32 to th e server 22 . properties to inherit properties set on their parent nodes, 

Th e parsing script 118, which runs at the server in the simplifying management tasks. These properties can span 

cont ext of authenti cated users, receives and p ames th e from virtual directories to physical directories or physical 

re quest (step 216). Recognizing the path query as pertai ning 55 directories to virtual directories. 

to lhe file system, th e script 110 invokes the file system The namespace integration mechanism is described in 
object 114 and denv_es _a nr**/ nhl& CLbased UbOU tlltf uusted— detail in a co-pending U.S. patent application Ser. No. 

'fi gtn (step 218). ITie file system de termines whether the path 09/105,398, entitled "Integration of Physical and Virtual 

is a real patn witmn trie pnysicid ^ectones'(sTCpr220)7lf the Namespace", which was filed Jun. 26, 1998 in the names of 

path is not contained_inJhe_phvsi^^ir^^ 60 Ronald Meijer, Douglas C. Hebenthal, Lara N. Dillingham, 



j^ lq" orancnlirom s tep^O), thc-serve r returns an erro r 
m essage in an Hi TP r esponse to the client (step 222). On the 
ot her hand , it tne path exists (i.e., the "yes" branch from step 
22 ty|, the hie sy stem object 114~grjm aefa4es4he~flles or t ne 
dire ctories in the patrr(step-224 )r" 

At step 226, the server side ASP script 118 creates a 
formatted dialog to return to the client browser. The ASP 
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Kim A. Stebbens, James D. Jacoby, and Anthony C. 
Romano. The application is assigned to Microsoft Corpo- 
ration and is hereby incorporated by reference. 

The above description focuses on remote file management 
using an HTML browser. It is noted that aspects of this 
invention may be extended to enable remote management of 
other local system resources, such as IP addresses, printers, 
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and so forth. Messages in the form of HTTP requests can be 
sent across and handled by server-side scripts. The scripts 
pass the messages onto the appropriate system resource. 
Then, when constructing a response, the server-side script 
generates a client-side script to be downloaded to the client 
to instantiate an object containing the requested data con- 
cerning the local system resource. 

Example of Server-Side Generation of Client-Side 
Script 

One of the aspects of the remote browsing process is that 
a server-side script creates on behalf of the client a client- 
side script that instantiates a custom client-side object to 
cache the returned file data. As one example, a server-side 
ASP file "jsbrwset.asp" is executed to create a set of files 
and/or folders from the server files system that can be cached 
at the client. The server-side ASP file is written in VBScript 
and, when executed, outputs a script written in JavaScript 
that can be executed on the client to create an object holding 
the file data returned in response to the browser query. The 
code for the ASP file is given below: 



<%@ LANGUAGE- VBScript %> 

<% Option Explicit %> 

<% Response. Expires - 0 %> 

<% 

Const L_PATHNOTFOUND_TEXT - "The path was not found." 
Const L_SLASH_TEXT = "\" 
Const TDIR - 0 
Const TFILE = 1 
Const FLXEDDISK - 2 

Dim i, newid,path, f, sc, fc, fl, FUeSystenijbtypejdrive, drives 
Dim primarydrive 

bType - Clnt(RequesL. Query string ("btype")) 
Set FileS ystem-CreateObject("Scripting.FileSystemObject") 
Set drives - File System. Drives 
For Each drive in drives 
primarydrive - drive 

'exit after the first FDCEDDISK if there is one . . . 
if drive.DriveType - FDCEDDISK then 

Exit For 
end if 

Next 

primarydrive - primarydrive & L_SLASH_TEXT 
newid - 0 

If Request.QueryString("path") <>" " Then 
path = Request.QueryString("path") 
if FileSystem.FolderExists(path) then 

Response.C^kies("HTMLA")( a LASTPATH'')=path 
end if 

Else 

path - Request.Cookies("HrMLA")C*LASTPATH") 
End If 

If path = " 'Then 

Response.Cc«kies( w HTMLA , X^STPATH , >primarydrive 

path - primarydrive 
End If 

%> 

<HTML> 
<HEAD> 

<SCRIPT LANGUAGE-"JavaScript"> 

<% if FileSystem. Folder Exists(path) then %> 
top.main.head.cachedList - new Array( ); 
cachedList » top.main.head.cachedList; 

<% 

Set f=FileSystem.GctFolder(path) 
Set sc = f.SubFoldere 
For Each i In sc 

if i.Attributes AND 2 then 

else 

%> 

cachedlist( <%- newid new 

top.main.head.listObj("<%- Replace (i"\","\V) 
%>","<%- i.rwme %>"" ","<%- i.Type 
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-continued 
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%>","<%= LDateLastModified %>",true); 

<% 

newid = newid + 1 
end if 

Next 

if bType - TFILE then 
Set fc - f.Files 
For Each fl in fc 

if fl.Attributes AND 2 then 

else 

%> 

cachedlist[<%- newid %>]- new 

top.main.head.listObj("<%- Replace(i,"Y7'\\") 
%>""<%- fl.name %>"," ","<%- fl.size 
%>""<%= fl.Typc %>""<%- 
fl.DateLastModified %>",false); 
<% 

newid - newid + 1 
end if 

Next 
end if 



%> 



top. main. head. listFunc.seI[ndex=0; 
top. main. list. location. href -"JSBrwLs.asp"; 
<% else %> 

alert(top.main.headdocument.userform.currentPath.vaIue+"\r\r<%- 

L_ PATH NOTFOU N D_TEXT %>"); 
top.main. head. document.userform.currentPath. value - "<%- 

Replace(RequesL Ccokies("HTMl^'0("LASTPATH f ')rV , ,*'\V') %>"; 
<% end if %> 
</SCRIPT> 
</HEAD> 
<BODY> 
</BODY> 
</IHTML> 



Notice that the end of the code contains instructions to 
create an HTML form written in JavaScript. Execution of the 
ASP file thereby creates an HTML form having a cached list 
of files/folders returned by the file system object. The HTML 
form output as a result of executing the ASP file is as 
follows: 



top.main.head.cachedList = new Array( ); cachedList - 
top.main.head.cachedList; 

cached List[0]» new 
top.main.head.IUtOb J "("C:\\WINN r r , , a WlNN r r , ) " V ""File Folder", 
"7/24/97 2:39:00 PM",true); 

cachedList( 1}= ncw 
top.main. head. lis tObj'("C:\\Inetpub" ) **Inetpub"" ","F[\c Folder", 
"7/31/97 8:45:28 PM'\true); 

cached Lis\[ 2 j- new top.main.head.listObj("C:\\Program Files", 
"Program Files"," "/File Folder"," 6/10/97 2:51:26 PM",true); 

cachedList[3}- new top.main.head.listObj("C:\\tempVtempV " 
"FUe FolderVll/12/97 11:19:54 PM",true); 

cached List[4]- new 
top-main-head-listObjC'CiWENROLU'/'ENROLL"," "," ""File Folder", 
"6/3/98 2:57:24 PM",true); 

cachedList[5]- new 
top.main.head.listObj("C:\\EFORM","EFORM" ( " ","File Folder", 
"11/4/97 2:48:06 PM",true); 

cached List[ 6]- new top.main.head.listObj("C:\\bin","bin", M 
"File Folder" ,"10/14/97 3:39:00 PM'\true); 

cachcdListf7]*» ncw 
top.main. head. lis tObj'("C:\\Benefits" "Benefits"," V ""File Folder", 
"12/19/97 3:46:06 PM",true); 

cachcdListf 8]» n« w top.main.head.listObj("C:\\MLO","MLO"," ",** " 
"File Folder'Vl/12/98 3:19:30 PM",true); 

cached List[9}- new top.mab.head.listObj("C:\\Multimedia 
Files","Multimedia Files"," ","File Folder", 
"7/28/97 5:54:30 PM",true); 

top.main.head.listFunc.selIndex-0; top. ma in. list, location, href 
-"JSBrwLs.asp"; 
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Although the invention has been described in language 
specific to structural features and/or methodological steps, it 
is to be understood that the invention defined in the 
appended claims is not necessarily limited to the specific 
features or steps described. Rather, the specific features and 
steps are disclosed as exemplary forms of implementing the 
claimed invention. 

What is claimed is: 

1. In a client-server computer system, a method for 
browsing server-based physical file directories remotely 
from a client over a network, comprising the following 
steps: 

submitting a directory path in a request from the client to 

the server, the directory path specifying a path in the 

physical file directories; 
generating directory data pertaining to files and/or folders 

enumerated for the directory path; 
creating client-side executable code for execution on the 

client to cache the directory data at the client; and 
returning the executable code and the directory data from 

the server to the client. 

2. A method as recited in claim 1, further comprising the 
step of executing the executable code at the client to cache 
the directory data at the client. 

3. A method as recited in claim 2, further comprising the 
step of displaying the directory data at the client. 

4. A method as recited in claim 2, further comprising the 
step of listing the files and/or folders in a graphical user 
interface at the client. 

5. A method as recited in claim 2, further comprising the 
step of displaying a representation of the file directories in 
a graphical user interface at the client, 

6. A method as recited in claim 1, further comprising the 
step of executing the executable code at the client to build 
a graphical user interface and to present the directory data 
within the graphical user interface at the client. 

7. A method as recited in claim 6, further comprising the 
step of navigating the directory data within the graphical 
user interface. 

8. A method as recited in claim 1, wherein the submitting 
step comprises the step of sending the directory path as a text 
string in an HTTP request. 

9. Computer-readable mediate distributed at the client and 
the server to store computer-executable instructions for 
performing the steps as recited in claim 1. 

10. In a client-server computer system iD which a client 
submits a request to browse a server-based file directory, a 
method for handling the client request at the server, com- 
prising the following steps: 

extracting a directory path from the request; 
enumerating any files and/or folders for the directory 
path; 

creating executable code for execution on the client to 
cache directory data pertaining to the enumerated files 
and/or folders at the client; and 

returning the executable code and the directory data to the 
client. 

11. A method as recited in claim 10, further comprising 
the step of determining whether the directory path exists. 

12. A remote file administration architecture embodied on 
computer-readable media for execution in a client-server 
system, the architecture comprising: 

client-side code resident at a client to enable a user to 
designate a path of a physical file directory located at 
a server and to send a client request that includes the 
path to the server; and 
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server-side code resident at the server to receive the client 
request and to generate directory data pertaining to files 
and/or folders for the directory path, the server-side 
code generating client-side executable code for execu- 
tion on the client to cache the directory data at the client 
and returning the executable code and the directory 
data to the client. 

13. A remote file administration architecture as recited in 
claim 12, wherein the client-side code comprises a Web 
browser and a graphical user interface to present and enable 
navigation of the directory data. 

14. A remote file administration architecture as recited in 
claim 12, wherein the server-side code comprises a Web 
server, a file system interface, and a script to generate the 
client-side executable code. 

15. A remote file administration architecture as recited in 
claim 12, wherein the request conforms to HTTP. 

16. A remote file administration architecture embodied on 
computer-readable media for execution in a client-server 
system having a client computer connected to a server 
computer via a public network, the server having a file 
system with files and/or folders arranged in physical 
directories, the architecture comprising: 

a client browser resident at a client; 

a client user interface to enable a user to designate a path 
of a physical file directory located at the server; 

the client browser being configured to send a client 
request that includes the path to the server; and 

a server program resident at the server to receive the client 
request and to direct the file system to enumerate the 
files and/or folders for the directory path contained in 
the request, the server program generating executable 
code that can be executed on the client to cache 
directory data enumerated by the file system at the 
client. 

17. A remote file administration architecture as recited in 
claim 16, wherein the request conforms to HTTP. 

18. A remote file administration architecture as recited in 
claim 16, wherein the server program returns the executable 
code and the directory data to the client. 

19. A server software system embodied on a computer- 
readable medium and implemented in a server connected to 
serve one or more clients, the server having a file system 
with files and/or folders arranged in physical directories, the 
server software system comprising: 

code means for receiving a client request to browse the 
file system, the client request specifying a directory 
path of a physical directory; 

code means for enumerating any files and/or folders for 
the directory path; 

code means for creating client-side executable code for 
execution on the client to cache directory data pertain- 
ing to the enumerated files and/or folders at the client; 
and 

code means for returning the executable code and the 
directory data to the client. 

20. A server software system as recited in claim 19, 
further comprising code means for determining whether the 
directory pass exists. 

21. A server operating system comprising the server 
software system as recited in claim 19. 

22. A network system comprising: 

a client computer having a processing unit, a memory, and 
a browser stored in the memory and executable on the 
processing unit; 

a server computer having a processing unit and memory; 
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a file system implemented on the server computer and 
having files and/or folders organized in directories and 
stored within the server memory; 

a server program stored in the server memory and execut- 
able on the processing unit to receive requests from the 5 
browser on the client computer and to return responses 
to the browser; 

the browser being configured to send a request to the 
server computer, the request specifying a directory path 
within the physical directories of the file system; and 
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the server program being configured to obtain directory 
data for the directory path from the file system and to 
create client-side executable code for execution on the 
client computer to cache the directory data locally at 
the client, the server program returning the executable 
code and the directory data to the client. 
23. A network system as recited in claim 22, wherein the 
client browser communicates with the server program using 
HTTP messages. 

***** 
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